Publication Date: YYYY-MM-DD
Approval Date: YYYY-MM-DD
Submission Date: YYYY-MM-DD
Reference number of this document: OGC 18-021
Reference URL for this document: http://www.opengis.net/doc/PER/t14-D040
Category: Public Engineering Report
Editor: Clemens Portele
Title: OGC Testbed-14: Complex Feature Handling Engineering Report
COPYRIGHT
Copyright © 2018 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
WARNING
This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.
LICENSE AGREEMENT
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
- 1. Summary
- 2. References
- 3. Terms and definitions
- 4. Overview
- 5. Use cases
- 5.1. Introduction
- 5.2. Managing and using a Cadastral dataset
- 5.2.1. Description
- 5.2.2. Selection of protected sites
- 5.2.3. Select the owners of cadastral parcels in an area
- 5.2.4. Select versions of cadastral parcels based on their temporal validity
- 5.2.5. Select cadastral parcels for rendering with a specific style
- 5.2.6. Selection of building parts of a building
- 5.3. Building heating demand simulation and visualization
- 5.3.1. Description
- 5.3.2. Data
- 5.3.3. Open a webpage to display a 3D map using 3D Portrayal Service and select a polygonal area / district
- 5.3.4. Using 3D Portrayal Service and WFS to query the simulation result and visualize it in a 3D scene by building Id
- 5.3.5. Query a feature from a city model by id
- 5.3.6. Select buildings in a 2D region from a city model
- 5.3.7. Select buildings based on nested features or properties
- 6. Requirements analysis
- 7. Assessment of OGC and community standards
- 8. Recommendations
- Appendix A: Revision History
- Appendix B: Bibliography
1. Summary
WFS 3.0 is a revision of the OGC Web Feature Service standard that proposes a modernized service architecture, that follows the current Web architecture, has a focus on the developer experience, supports the OpenAPI specification, and modularizes WFS into building blocks for fine-grained access to spatial data that can be used in data APIs.
This document reviews the work on this next generation of OGC web services ("NextGen services") from the perspective of supporting complex 3D data or complex data schemas. The goal is to identify the best service solution for these particular needs, whether the result are WFS 3.0 extensions or other approaches. In this context the approach that the NextGen services are not monolithic web services, but API building blocks, is important. The same API should be able to support requirements that currently require separate OGC web services, e.g. a WFS and a 3DPS server.
The report will eventually propose how to extend the NextGen service architecture with API building blocks for complex data, complex queries and 3D portrayal. WFS 3.0, Part 1, is used as the starting point for the NextGen service architecture. The proposals will be based on existing requirements and use cases. They should be developer-friendly.
|
Note
|
TODO Add key results later in the testbed in a concise form. |
1.1. Requirements & Research Motivation
The current work on WFS 3.0 has focused on simple features and interaction, interrogation and extraction of these. However there are more complex use cases that require 3D data and/or more complex data schemas to achieve a users desired outcome.
This report will document real-world use cases and requirements that feature servers will have to support in the future, besides the essential capabilities specified in Part 1 of the WFS 3.0 series. These will include the following:
-
Querying / filtering features based on properties of related or nested objects or structured data types, including cases where more that one level of relationships/nesting is used;
-
Querying / filtering features based on expressions build from complex predicates consisting of predicate groups and combinations of logical operators;
-
Querying feature data and returning only parts of the features (selected properties, a single property only, etc.);
-
Access to and query of solid geometries and other geometries in a 3D CRS;
-
Use of responses for display in a web browser;
-
Accessing different versions (including historic representations) of features.
The use cases will cover aspects like CityGML, CityGML ADEs, 3DPS, and WFS 2.0 interactions, but use other complex data schemas as background, too.
Based on the identified requirements, this report will address the following aspects:
-
Assessment of what use cases, especially those that utilise 3D or more complex data schemas, would require more complex interactions than the current WFS 3.0, Part 1, draft would provide;
-
Assessment of current OGC standards and community standards on the basis of both supporting the uses cases captured and alignment to NextGen service approaches, including a review around the interaction between 3DPS and WFS 2.0.
-
Recommendations for the most appropriate way to support these use cases within the NextGen service architecture;
Developer requirements will be taken into account in the design. That is, the implementation of the proposed design should be as simple as possible (given the advanced, complex requirements). This includes research for available libraries that support implementations. The OGC community is not the only one implementing rich queries on complex data.
1.2. Prior-After Comparison
The current work on WFS 3.0 in the WFS/FES SWG has focused on simple features and interaction, interrogation and extraction of these. However there are more complex use cases that require 3D data and/or more complex data schemas to achieve a users desired outcome.
This work will propose extensions to the NextGen service architecture to support such use cases.
Initial discussions about related topics are:
-
Placeholder issue in the WFS 3.0 repository for richer query capabilities: WFS 3.0 Search extension
-
REST binding in the WFS 2.x and FES 2.x draft specifications: Document folder in the OGC portal (only accessible to OGC WFS/FES SWG members)
Like the work in the WFS/FES SWG on WFS 3.0, the work on this report will be open to the public from the beginning in order to get feedback from developers as early as possible.
The formal review of the draft report before it will be submitted to the OGC Technical Committee for consideration and publication as an OGC Engineering Report will be by the WFS/FES SWG.
1.3. Recommendations for Future Work
|
Note
|
TODO This section will be added later and discuss what aspects should be addressed next and which actions are necessary. |
1.4. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Contacts
| Name | Organization |
|---|---|
Clemens Portele (editor) |
interactive instruments GmbH |
Volker Coors |
Hochschule für Technik Stuttgart |
1.5. Foreword
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
2. References
The following normative documents are referenced in this document.
-
OGC: OGC Web Feature Service 3.0: Part 1 - Core, Version 3.0.0-draft.1 (OGC 17-069)
-
Open API Initiative: OpenAPI Specification 3.0.1
3. Terms and definitions
The following terms and definitions apply:
- OpenAPI definition | OpenAPI document
-
a document (or set of documents) that defines or describes an API and conforms to the OpenAPI Specification
[derived from OpenAPI Specification]
4. Overview
Section 5 documents real-world use cases and requirements that more advanced feature servers will have to support in the future, besides the essential capabilities specified in Part 1 of the WFS 3.0 series.
Section 6 analyses the use cases and identifies the requirements that would require more complex interactions than those supported by the current draft of WFS 3.0, Part 1.
Section 7 assesses current OGC standards and community standards with respect to the use cases and the approach to a next generation of OGC services ("NextGen services") based on the approach taken by WFS 3.0.
Section 8 provides recommendations for the most appropriate way to support the use cases within the NextGen service architecture.
5. Use cases
5.1. Introduction
This section will document real-world use cases and requirements that more advanced feature servers should support in the future, besides the essential capabilities specified in Part 1 of the WFS 3.0 series.
All query examples are used in practice, either as queries submitted by a client, in stored queries of a WFS or in SLD/SE documents defining layers based on feature data.
The use cases will cover aspects like CityGML, CityGML ADEs, 3DPS, and WFS 2.0 interactions, but use other complex data schemas, too.
For each use case example, the aspects are identified why the example has been included in this report. There is at least one example for each of the following aspects:
-
Querying features based on properties of related or nested objects or structured data types (one level)
-
Querying features based on properties of related or nested objects or structured data types (several levels)
-
Querying features based on expressions built from complex predicates consisting of predicate groups and combinations of logical operators
-
Querying feature data and returning only parts of the features (selected properties, a single property only, etc.)
-
Querying feature data and returning additional features linked to the selected features
-
Access to and query of solid geometries and other geometries in a 3D CRS
-
Use of responses for display in a web browser
-
Accessing different versions (including historic representations) of features
5.2. Managing and using a Cadastral dataset
5.2.1. Description
The dataset used in this section is about cadastral parcels and related information. It is using the AFIS-ALKIS-ATKIS application schema of the Surveying Authorities in Germany. The GML application schema is the NAS.
The application schema is optimised for maintaining the data by the Surveying Authorities and reflects the legal requirements. As a result, the application schema contains many relationships between feature types as well as structured data types. The application schema includes information related to portrayal of the data at map scales that are traditionally used for base maps, too. For example, information is included about text placement in specific maps.
Since the cadastral law permits arcs in a boundary of a cadastral parcel, Simple Feature geometries are not sufficient for storing the authoritative feature data.
Outside of the Surveying Authorities the data is often simplified / flattened to simplify the use of the data, but a number of workflows require the full use of the complex data structures included in the dataset.
As the application schema is used in Germany, it uses German terms. For better readability we show a simplified schema using English translation for each query described in this section.
5.2.2. Selection of protected sites
This is a relatively simple use case where features are selected based on properties of related features, i.e. features that are the value of an association role property.
The following aspects are covered by this use case:
-
Querying features based on properties of related or nested objects or structured data types (one level)
-
Querying feature data and returning additional features linked to the selected features
Data
The queries use the following feature types:
- ProtectedSite_Water (AX_SchutzgebietNachWasserrecht)
-
A protected site based on laws pertaining to water and waterways. It consists of one or more zones.
- ProtectedZone (AX_Schutzzone)
-
An area in a protected site with a homogeneous classification.
Query 1: Select just the protected site features
The following WFS query selects all ProtectedSite_Water (AX_SchutzgebietNachWasserrecht)
features that have a protected zone in a given bounding box using a value reference
contains/ProtectedZone/position (adv:bestehtAus/adv:AX_Schutzzone/adv:position).
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_SchutzgebietNachWasserrecht&
filter=
<fes:Filter
xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Intersects>
<fes:ValueReference>
adv:bestehtAus/adv:AX_Schutzzone/adv:position
</fes:ValueReference>
<gml:Envelope
srsName="http://www.opengis.net/def/crs/epsg/0/25832">
<gml:lowerCorner>360000 5600000</gml:lowerCorner>
<gml:upperCorner>370000 5700000</gml:upperCorner>
</gml:Envelope>
</fes:Intersects>
</fes:Filter>The result is a feature collection with four ProtectedSite_Water (AX_SchutzgebietNachWasserrecht) features.
Query 2: Select also the related protected zone features
The following WFS query selects not only the ProtectedSite_Water (AX_SchutzgebietNachWasserrecht)
features that have a protected zone in a given bounding box, but uses the
WFS resolve and resolvedepth parameters to retrieve all the zone features in the same query.
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_SchutzgebietNachWasserrecht&
resolve=local&
resolvedepth=1&
filter=
<fes:Filter
xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Intersects>
<fes:ValueReference>
adv:bestehtAus/adv:AX_Schutzzone/adv:position
</fes:ValueReference>
<gml:Envelope
srsName="http://www.opengis.net/def/crs/epsg/0/25832">
<gml:lowerCorner>360000 5600000</gml:lowerCorner>
<gml:upperCorner>370000 5700000</gml:upperCorner>
</gml:Envelope>
</fes:Intersects>
</fes:Filter>The result is a feature collection with four ProtectedSite_Water (AX_SchutzgebietNachWasserrecht) features and one ProtectedZone (AX_Schutzzone) feature in each site.
5.2.3. Select the owners of cadastral parcels in an area
This use case is similar to the previous one, but uses value references along multiple associations.
The following aspects are covered by this use case:
-
Querying features based on properties of related or nested objects or structured data types (several levels)
Data
The dataset is the same as in the previous use case.
The example query use the following feature types. This is simplified, the actual schema and data is much more complex and reflects the legal requirements of the German land register.
- CadastralParcel (AX_Flurstueck)
-
A cadastral parcel.
- Record (multiple feature types)
-
An entry in the land register.
- Person (AX_Person)
-
A person that has some rights or responsibilities related to one or more parcels.
Query
The following WFS query selects all Person (AX_Person) features, that are
related to cadastral parcels in a bounding box, e.g. own the parcel or
have some rights. The filter uses a value reference along
multiple associations: partOf/Record/relatedTo/CadastralParcel/position
(the first value reference) or
partOf/Record/related/Record/relatedTo/CadastralParcel/position
(the second value reference).
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_Person&
filter=
<fes:Filter
xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Or>
<fes:Intersects>
<fes:ValueReference>
adv:weistAuf/adv:AX_Namensnummer/adv:istBestandteilVon/
adv:AX_Buchungsblatt/adv:bestehtAus/adv:AX_Buchungsstelle/
adv:grundstueckBestehtAus/adv:AX_Flurstueck/adv:position
</fes:ValueReference>
<gml:Envelope
srsName="http://www.opengis.net/def/crs/epsg/0/25832">
<gml:lowerCorner>361000 5610000</gml:lowerCorner>
<gml:upperCorner>362000 5620000</gml:upperCorner>
</gml:Envelope>
</fes:Intersects>
<fes:Intersects>
<fes:ValueReference>
adv:weistAuf/adv:AX_Namensnummer/adv:istBestandteilVon/
adv:AX_Buchungsblatt/adv:bestehtAus/adv:AX_Buchungsstelle/
adv:an/adv:AX_Buchungsstelle/adv:grundstueckBestehtAus/
adv:AX_Flurstueck/adv:position
</fes:ValueReference>
<gml:Envelope
srsName="http://www.opengis.net/def/crs/epsg/0/25832">
<gml:lowerCorner>361000 5610000</gml:lowerCorner>
<gml:upperCorner>362000 5620000</gml:upperCorner>
</gml:Envelope>
</fes:Intersects>
</fes:Or>
</fes:Filter>The result is a feature collection with the person features matching the query.
Due to privacy regulations, the land register data is not open data and no live query link can be provided.
5.2.4. Select versions of cadastral parcels based on their temporal validity
Often, the history of a dataset is important. The example that we are using here is a cadastral parcel dataset, where it can be important to know the state of the parcels at a point in the past.
There are two options how this is typically handled in application schemas.
One approach is that the features are in fact feature versions. That is, different versions of the same feature / real-world entity are each represented as separate features. This is the approach we are considering in this use case. To avoid confusion we use the terms "version" and "real-world entity" in the description of this use case instead of "feature" which could mean the feature or a specific version of the feature.
The advantage of this approach is that no specific temporal support is required in clients processing the data. This pattern is therefore frequently used with data that is used in map-based GIS clients, for example, with dataset provided by mapping or cadastral agencies.
The other approach is to model the feature properties as timestamped sequences of values. GML supports this approach with the Dynamic Features pattern. The downside of this approach is that clients and servers must support this specific pattern, which typically requires customised software. A domain that is using this approach is the aviation domain.
The following aspects are covered by this use case:
-
Accessing different versions (including historic representations) of features
Data
The dataset is the same as in the first use case.
As described above, the features in the application schema are versions of a real-world entity, valid for a given time period.
All versions of the same real-world entity have the same gml:identifier.
If multiple versions occur in the same GML document, a timestamp will be added
to the gml:id attribute, otherwise the identifier of the real-world entity
will be used.
Each version has information about the lifespan of the version at hand. I.e., each version has a timestamp when this version has been added to the dataset. If the version is still valid, there is no timestamp for the end of the version validity. If the version (or the real-world entity) is no longer valid in the dataset, a timestamp for the end is added.
Each timestamp is given in UTC, the granularity is seconds.
If a new version is added due to a change in a property, the new version will have a start timestamp that is one second after the end timestamp of the previous version.
The example query use the following feature type. The actual schema and data is more complex and has been simplified to the relevant aspects for this use case.
- CadastralParcel (AX_Flurstueck)
-
A cadastral parcel.
Query
The following WFS query selects all CadastralParcel (AX_Flurstueck) versions that have been inserted into the dataset on July 1st, 2017.
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_Flurstueck&
filter=
<fes:Filter
xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:During>
<fes:ValueReference>
adv:lebenszeitintervall/adv:AA_Lebenszeitintervall/adv:beginnt
</fes:ValueReference>
<gml:TimePeriod gml:id="TP1">
<gml:begin>
<gml:TimeInstant gml:id="TI1">
<gml:timePosition>2017-07-01T00:00:00Z</gml:timePosition>
</gml:TimeInstant>
</gml:begin>
<gml:end>
<gml:TimeInstant gml:id="TI2">
<gml:timePosition>2017-07-01T23:59:59Z</gml:timePosition>
</gml:TimeInstant>
</gml:end>
</gml:TimePeriod>
</fes:During>
</fes:Filter>The result is a feature collection with eight CadastralParcel (AX_Flurstueck) features.
Note that the dataset accessible via the WFS only includes valid versions, because WFS 2.0 does not include a simple mechanism to handle versions in queries and most users, especially those using a map-based GIS client, would be surprised to receive multiple features from the WFS representing the same real-world entity. All of those version would be drawn on a map at the same time.
There is an opportunity with WFS 3.0 to support datasets with versions natively.
See also the related discussion in the W3C/OGC Spatial Data on the Web Best Practice document.
5.2.5. Select cadastral parcels for rendering with a specific style
A common requirement is to present features in a dataset on a map (or in a 3D scene). In this use case we look at rendering feature data on a 2D map, for display in a web browser.
This may be implemented using a WFS 2.0 as the backend, i.e. the rendering engine is a WFS client and then renders the data, either directly in the browser or in a server, for example, a WMS 1.3.
For server-side rendering, the data will typically be rendered closer to the database and not via a WFS 2.0 interface - for performance reasons. For client-side rendering, the data will typically not use GML, but a format that is optimised for the rendering purpose. Nevertheless, the use case is still relevant in the context of complex feature handling, for at least two reasons:
-
Style information in the OGC standards baseline uses Symbology Encoding and the feature selection mechanisms are the same as in WFS 2.0 - both use the Filter Encoding standard.
-
In this report, we are not limited to WFS only, but we want to consider other aspects that are relevant for future OGC NextGen services, too. As OGC NextGen services will have to be able to support API building blocks for providing maps, scenes, vector tiles, etc., the related query aspects need to be considered, too.
The following aspects are covered by this use case:
-
Querying features based on expressions built from complex predicates consisting of predicate groups and combinations of logical operators
-
Use of responses for display in a web browser
Data
The dataset is the same as in the first use case.
The example query uses the following feature types. The actual schema and data is more complex and has been simplified to the relevant aspects for this use case.
- CadastralParcel (AX_Flurstueck)
-
A cadastral parcel.
- Text (AP_PTO)
-
A map text for display on a map for a feature.
Query
Rich, standardised symbology rule sets exist for the cadastral datasets consisting of a large number of selection rules and feature styles.
We will use rules RUL06410 and RUL06420 from this portrayal catalogue as an example. The rules select all cadastral parcels that meet the following criteria (for display of the parcel number on the map):
-
Parcels in a local district are identified using a numerator ("Zähler") and an optional denominator ("Nenner"). The example rules only apply to parcels with a denominator. The value reference is
numerator(adv:flurstuecksnummer/adv:AX_Flurstuecksnummer/adv:nenner). -
In addition, all of the following conditions must be met:
-
Another organisation than the land register may be legally responsible for some parcels. This is indicated in a boolean attribute for an alternative legal status ("abweichenderRechtszustand"). The example rules only apply to parcels for which the attribute is either missing or
false. The value reference isaltLegalStatus(adv:abweichenderRechtszustand). -
The application schema includes special feature types to capture map placement information. A typical example is a Text object (AP_PTO), which may be used to provide a fixed location for a text on the map ("position") or to provide a different text ("schriftinhalt") than the default text derived from the properties of the real-world thing. An association exists between the cadastral parcel and the Text objects that contain information overriding the default portrayal on the map ("inversZu_dientZurDarstellungVon_AP_PTO"). Since a map may contain multiple texts for a feature, there is also a type property ("art") to distinguish different text types. The example rules only apply to parcels that have an associated Text object for displaying the parcel number on the map (type is "ZAE_NEN"). The value reference is
textOnMap/Text[type = 'ZAE_NEN'](adv:inversZu_dientZurDarstellungVon_AP_PTO/adv:AP_PTO[adv:art = 'ZAE_NEN']).
-
The difference between the two rules RUL06410 and RUL06420 is whether the
text on the map is taken from the numerator attribute of the cadastral parcel
feature or from the text attribute of the associated Text object.
The following WFS query selects all CadastralParcel (AX_Flurstueck)
features that are rendered using the example portrayal rules. The <fes:Filter>
part would be the same in a portrayal rule according to the Symbology Encoding
standard as used in a WMS/SLD.
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_Flurstueck&
filter=
<fes:Filter xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:And>
<fes:Not>
<fes:PropertyIsNull>
<fes:ValueReference>
adv:flurstuecksnummer/adv:AX_Flurstuecksnummer/adv:nenner
</fes:ValueReference>
</fes:PropertyIsNull>
</fes:Not>
<fes:And>
<fes:Or>
<fes:PropertyIsNull>
<fes:ValueReference>
adv:abweichenderRechtszustand
</fes:ValueReference>
</fes:PropertyIsNull>
<fes:PropertyIsEqualTo>
<fes:ValueReference>
adv:abweichenderRechtszustand
</fes:ValueReference>
<fes:Literal>false</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Or>
<fes:Not>
<fes:PropertyIsNull>
<fes:ValueReference>
adv:inversZu_dientZurDarstellungVon_AP_PTO/adv:AP_PTO[adv:art = 'ZAE_NEN']
</fes:ValueReference>
</fes:PropertyIsNull>
</fes:Not>
</fes:And>
</fes:And>
</fes:Filter>The result is a feature collection with more than 234,000 CadastralParcel (AX_Flurstueck) features.
5.2.6. Selection of building parts of a building
This use case has been added to include a query that - while not overly complex - cannot be executed with most WFS implementations as it would require support for spatial joins.
Including this use case does imply that WFS 3.0 should include an extension that supports such a query. However, as spatial relations are an important aspect of spatial data, we should at least include it in our considerations, even if we recommend to include explicit spatial relations in the feature representations, consistent with the recommendations of the W3C/OGC Spatial Data on the Web Best Practice document.
Data
The AFIS-ALKIS-ATKIS application schema distinguishes between buildings and building parts, where a building part is a part of a building with different characteristics, for example, a different number of floors. The 2D footprint geometry of a building part is within the footprint geometry of the building.
|
Note
|
The CityGML Building and BuildingPart features were originally modelled after the cadastral model in Germany. |
As the AFIS-ALKIS-ATKIS application schema is designed for maintaining the cadastral datasets, they do not contain a (redundant) association to identify the building parts within a build (as the relationship can be determined from the footprint geometries).
The queries use the following feature types:
- Building (AX_Gebaeude)
-
A permanent construction that must be recorded due its significance for the cadastre.
- BuildingPart (AX_Bauteil)
-
A part of a Building with distinct or special characteristics.
Query
Two subsequent queries are required.
The first query retrieves the building using its identifier (DENW45AL0000lxrJ)
in order to determine the footprint geometry of the building.
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
resourceId=DENW45AL0000lxrJThe geometry can now be used to retrieve all building parts of that building.
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_Bauteil&
filter=
<fes:Filter
xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Intersects>
<fes:ValueReference>
adv:position
</fes:ValueReference>
<gml:Polygon gml:id="o31001.id.29956334.position.Geom_0" srsName="urn:ogc:def:crs:EPSG::25832">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
377034.58 5658143.873 377036.274 5658136.338 377036.438 5658135.613
377038.889 5658136.168 377039.429 5658136.291 377043.42 5658137.194
377043.262 5658137.895 377041.564 5658145.455 377041.193 5658145.371
377038.311 5658144.715 377034.58 5658143.873
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</fes:Intersects>
</fes:Filter>The result is a feature collection with two BuildingPart (AX_Bauteil) features.
5.3. Building heating demand simulation and visualization
5.3.1. Description
This section is about using 3D city models to simulate the building’s heating demand and visualize the results in a web-based 3D scene. Why is this relevant? The building sector has large potential for energy efficiency gains and CO2-reductions and is thus a priority area for achieving the ambitious climate and energy targets for 2020 and 2050 in the European Union [1]. In order to reach the 2% energy refurbishment rate promoted by the European Union and to realise long-term climate neutral communities, information about the current and future demand is necessary in order to develop strategies for policy making as well as to raise awareness of the citizens. Some pioneering work has already been done world wide [2], [3], [4], [5]. As an input for the simulation, a building model in CityGML is usually used. The use case is split into several parts:
-
open a website to display a 3D map using 3D Portrayal Service and select a polygonal area / district
-
query 3D building geometry inside the polygonal area from a CityGML data store using WFS 3.0 as an input to the simulation
-
using 3D Portrayal Service and WFS 3.0 to query the simulation result and visualize it in a 3D scene by building Id, by address, and by polygonal area
-
exend the use case to the INSPIRE 3D building module in addition to CityGML
The following aspects are covered:
-
Querying features based on properties of related or nested objects or structured data types (one level / several levels)
-
Querying feature data and returning only parts of the features (selected properties, a single property only, etc.)
-
Querying feature data and returning additional features linked to the selected features
-
Access to and query of solid geometries and other geometries in a 3D CRS
-
Use of responses for display in a web browser
5.3.2. Data
-
Open data 3D city model New York as used in Testbed 13 S3D performance. CityGML LoD 1/2 Building Model, no Textures http://www1.nyc.gov/site/doitt/initiatives/3d-building.page; heating demand simulation is available (monthly energy balance) for Manhattan as "as is" simulation (simulated with SimStadt Software, HFT Stuttgart).
-
Open data 3D model of Essen as used in the Energy and Location Pilot of the JRC. CityGML LoD 1/2 Building Model, no Textures; heating demand simulation is available (monthly energy balance) as "as is" simulation, medium refurbishment scenario, advanced refurbishment scenario (simulated with SimStadt Software, HFT Stuttgart).
-
Open data 3D model of Essen, a test area converted from CityGML to INSPIRE building model using HALE Studio.
5.3.3. Open a webpage to display a 3D map using 3D Portrayal Service and select a polygonal area / district
This has been showcased and implemented in Testbed 13 [6]. The implementation is available and could be further used and extended in Testbed 14 with the New York data set. The experiment evaluated the complete flow of data from its originating CityGML format to a web-enabled visualization with Cesium via OGC’s 3D Portrayal Service (3DPS). This data flow included the conversion from the CityGML data format served by GeoRocket, to 3D Tiles dataset, and the import of the 3D Tiles dataset to the 3DPS Framework.
A public demo is available at: http://tb13.igd.fraunhofer.de:8080/Apps/Sandcastle/index.html?src=3DPS_r.html&label=Showcases.
The following aspects are covered by this use case:
-
Use of responses for display in a web browser (3DPS getScene Region query)
Query
A 3DPS getScene request example from the New York showcase:
|
Caution
|
The link appears to be broken. |
In the existing implementation, 3D Tiles is used as content delivery format. See OGC Testbed 13 – 3D Tiles and I3S Interoperability and Performance Engineering Report [6], experiment 2 for further details.
5.3.4. Using 3D Portrayal Service and WFS to query the simulation result and visualize it in a 3D scene by building Id
In Testbed 13, the 3DPS getFeatureInfo request has been used to query heating demand (simulation result) per building from a server at HFT Stuttgart. See video on the Testbed 13 S3D Performance Experiment #2.
It would make sense to user the building id to retrieve additional attributes from a WFS. But the building geometry is not wanted any more as it is already available.
The following aspects are covered by this use case:
-
Use of responses for display in a web browser (3DPS getScene Region query)
-
Querying feature data and returning only parts of the features (selected properties, a single property only, etc.)
Query
A 3DPS getFeatureInfo request example from the New York showcase:
As this is requesting feature properties, such a request could also be directed
to a WFS 2.0 with the building model. The building would be selected based on its
identifier using the resourceId parameter. The property parameter could be
used to select only the desired properties (in the example below: the building
function, the measured height and heat information); properties that are not
needed, for example, the geometry, would be excluded from the response.
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
resourceId=uuid_2824afd6-00e5-42ac-ab95-ec868595dc5a&
propertyName=function,measuredHeight,heatWFS 3.0 should include an extension that supports such a capability, too.
5.3.5. Query a feature from a city model by id
Most important in this use case is that solids are supported as feature geometries.
In addition, it needs to be discussed how to deal with the LoD concept of CityGML. The CityGML model that is retrieved will typically be used by another process - in our example the simulation of the heating demand of that building.
Query
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
resourceId=TWINHOUSE1In WFS 3.0, the building would be identified by a URI, for example, http://www.example.com/my-city-model/collections/buildings/items/TWINHOUSE1.
As mentioned above, the most important aspect in this query is that the WFS supports solid geometries and is able to return features with such geometries.
A WFS 2.0 would return the building feature in a wfs:FeatureCollection.
<wfs:FeatureCollection xmlns:xAL="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" xmlns:gml="http://www.opengis.net/gml" xmlns:bldg="http://www.opengis.net/citygml/building/2.0" xmlns:wfs="http://www.opengis.net/wfs/2.0" xmlns:gen="http://www.opengis.net/citygml/generics/2.0" xmlns:core="http://www.opengis.net/citygml/2.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/citygml/building/2.0 http://schemas.opengis.net/citygml/building/2.0/building.xsd http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd http://www.opengis.net/citygml/generics/2.0 http://schemas.opengis.net/citygml/generics/2.0/generics.xsd" timeStamp="2018-03-28T15:01:47" numberMatched="2" numberReturned="2">
<wfs:member>
<wfs:FeatureCollection timeStamp="2018-03-28T15:01:47" numberMatched="1" numberReturned="1">
<wfs:member>
<bldg:Building gml:id="TWINHOUSE1">
<gml:boundedBy>
<gml:Envelope srsName="crs:EPSG::31468" srsDimension="3">
<gml:lowerCorner>-8.0E-15 0.0 0.0</gml:lowerCorner>
<gml:upperCorner>10.04 10.04 6.4</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>
<core:creationDate>2018-03-20</core:creationDate>
<bldg:lod1Solid>
<gml:Solid gml:id="UUID_836b4b28-24d9-4e83-906a-98f4364d351f">
<gml:exterior>
<gml:CompositeSurface gml:id="UUID_2ac22267-11d4-48f0-b63d-c417228d1968">
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_e379198f-7e10-43e8-8737-851cece07579">
<gml:exterior>
<gml:LinearRing gml:id="UUID_e379198f-7e10-43e8-8737-851cece07579_0_">
<gml:posList srsDimension="3">2.0E-15 10.04 0.0 4.0E-15 10.04 1.0E-13 -0.0 0.0 0.0 2.0E-15 10.04 0.0</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_0e264d5e-3034-43fc-b65f-2b231ef5907b">
<gml:exterior>
<gml:LinearRing gml:id="UUID_0e264d5e-3034-43fc-b65f-2b231ef5907b_0_">
<gml:posList srsDimension="3">4.0E-15 10.04 1.0E-13 4.0E-15 0.0 1.0E-13 -0.0 0.0 0.0 4.0E-15 10.04 1.0E-13</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_c8dbcf60-8f0e-43f1-a1ef-ed43620dbfb1">
<gml:exterior>
<gml:LinearRing gml:id="UUID_c8dbcf60-8f0e-43f1-a1ef-ed43620dbfb1_0_">
<gml:posList srsDimension="3">4.0E-15 10.04 1.0E-13 10.04 10.04 0.0 10.04 0.0 0.0 4.0E-15 0.0 1.0E-13 4.0E-15 10.04 1.0E-13</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_22c99934-a675-4b42-97af-f73874d1aabb">
<gml:exterior>
<gml:LinearRing gml:id="UUID_22c99934-a675-4b42-97af-f73874d1aabb_0_">
<gml:posList srsDimension="3">10.04 0.0 6.4 10.04 0.0 0.0 10.04 10.04 0.0 10.04 10.04 6.4 10.04 0.0 6.4</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_13db3bd0-6210-414c-b884-3bd2099c9680">
<gml:exterior>
<gml:LinearRing gml:id="UUID_13db3bd0-6210-414c-b884-3bd2099c9680_0_">
<gml:posList srsDimension="3">10.04 10.04 6.4 10.04 10.04 0.0 4.0E-15 10.04 1.0E-13 2.0E-15 10.04 0.0 -8.0E-15 10.04 6.39999999999999 10.04 10.04 6.4</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_024dfb16-831c-4404-9c94-cdda06aaca86">
<gml:exterior>
<gml:LinearRing gml:id="UUID_024dfb16-831c-4404-9c94-cdda06aaca86_0_">
<gml:posList srsDimension="3">2.0E-15 10.04 0.0 -0.0 0.0 0.0 -8.0E-15 10.04 6.39999999999999 2.0E-15 10.04 0.0</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_a9f8e079-5033-49ed-851a-aae7f9454dd8">
<gml:exterior>
<gml:LinearRing gml:id="UUID_a9f8e079-5033-49ed-851a-aae7f9454dd8_0_">
<gml:posList srsDimension="3">-8.0E-15 10.04 6.39999999999999 -0.0 0.0 0.0 -8.0E-15 0.0 6.39999999999999 -8.0E-15 10.04 6.39999999999999</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_a6d3c8c7-ace0-4e48-b8c1-ca18cd5a814d">
<gml:exterior>
<gml:LinearRing gml:id="UUID_a6d3c8c7-ace0-4e48-b8c1-ca18cd5a814d_0_">
<gml:posList srsDimension="3">10.04 0.0 6.4 -8.0E-15 0.0 6.39999999999999 -0.0 0.0 0.0 4.0E-15 0.0 1.0E-13 10.04 0.0 0.0 10.04 0.0 6.4</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_c1b51c00-2dbc-45d2-9c93-c9b396382780">
<gml:exterior>
<gml:LinearRing gml:id="UUID_c1b51c00-2dbc-45d2-9c93-c9b396382780_0_">
<gml:posList srsDimension="3">-8.0E-15 10.04 6.39999999999999 -8.0E-15 0.0 6.39999999999999 10.04 0.0 6.4 10.04 10.04 6.4 -8.0E-15 10.04 6.39999999999999</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
</gml:CompositeSurface>
</gml:exterior>
</gml:Solid>
</bldg:lod1Solid>
<bldg:lod1TerrainIntersection>
<gml:MultiCurve>
<gml:curveMember>
<gml:LineString>
<gml:posList srsDimension="3">10.04 0.0 0.0 10.04 10.04 0.0</gml:posList>
</gml:LineString>
</gml:curveMember>
<gml:curveMember>
<gml:LineString>
<gml:posList srsDimension="3">-0.0 0.0 0.0 10.04 0.0 0.0</gml:posList>
</gml:LineString>
</gml:curveMember>
<gml:curveMember>
<gml:LineString>
<gml:posList srsDimension="3">2.0E-15 10.04 0.0 -0.0 0.0 0.0</gml:posList>
</gml:LineString>
</gml:curveMember>
<gml:curveMember>
<gml:LineString>
<gml:posList srsDimension="3">2.0E-15 10.04 0.0 10.04 10.04 0.0</gml:posList>
</gml:LineString>
</gml:curveMember>
</gml:MultiCurve>
</bldg:lod1TerrainIntersection>
</bldg:Building>
</wfs:member>
</wfs:FeatureCollection>
</wfs:member>INSPIRE recommends the use of wfs:FeatureCollection, too, but if the data
is not accessed via a WFS other feature collections may be used as well.
CityGML itself also includes a feature collection element, core:CityModel,
that may be used, if the service interface is not a WFS 2.0.
<core:CityModel xmlns:smil20="http://www.w3.org/2001/SMIL20/" xmlns:grp="http://www.opengis.net/citygml/cityobjectgroup/1.0" xmlns:smil20lang="http://www.w3.org/2001/SMIL20/Language" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:base="http://www.citygml.org/citygml/profiles/base/1.0" xmlns:luse="http://www.opengis.net/citygml/landuse/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:frn="http://www.opengis.net/citygml/cityfurniture/1.0" xmlns:dem="http://www.opengis.net/citygml/relief/1.0" xmlns:tran="http://www.opengis.net/citygml/transportation/1.0" xmlns:wtr="http://www.opengis.net/citygml/waterbody/1.0" xmlns:tex="http://www.opengis.net/citygml/texturedsurface/1.0" xmlns:core="http://www.opengis.net/citygml/1.0" xmlns:xAL="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" xmlns:bldg="http://www.opengis.net/citygml/building/1.0" xmlns:sch="http://www.ascc.net/xml/schematron" xmlns:app="http://www.opengis.net/citygml/appearance/1.0" xmlns:veg="http://www.opengis.net/citygml/vegetation/1.0" xmlns:gml="http://www.opengis.net/gml" xmlns:gen="http://www.opengis.net/citygml/generics/1.0">
<core:cityObjectMember>
<bldg:Building gml:id="TWINHOUSE1">
...
</bldg:Building>
</core:cityObjectMember>
</core:CityModel>In WFS 3.0 the response will be determined by the encoding and the requirements of the conformance class for that encoding.
None of the WFS 3.0 Core conformance classes for encodings supports solid geometries.
However, for responses that are CityGML 2.0, the same wfs30:FeatureCollection
element could be used that is also used in the WFS 3.0 conformance classes for the GML Simple Feature encodings.
Another option could be a WFS 3.0 that returns CityJSON.
5.3.6. Select buildings in a 2D region from a city model
In this example, all buildings in a rectangular region are requested and the selected building features are returned in a feature collection.
Query
Here is an example of a WFS 2.0 query:
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
BBOX=-74,40.7,-73.96,40.8Using an instance of GeoRocket containing the New York City CityGML model developed in Testbed 13 the request could also be:
This link points to a live service, but returns a large response. A more manageable response can be retrieved with a smaller bounding box.
In WFS 3.0, the request is also supported by the query capabilities of the Core, for example:
5.3.7. Select buildings based on nested features or properties
These examples have been provided by Claus Nagel, virtualcitySYSTEMS. They cover the following query categories:
-
Querying features based on properties of related or nested objects or structured data types (several levels)
-
Access to and query of solid geometries and other geometries in a 3D CRS
Query 1: Select buildings based on their ground surface geometry
This query retrieves all buildings having one or more ground surfaces whose LoD2 geometry intersects with a given geometry. bldg:GroundSurface is a nested feature.
In this example, the query geometry is a multi surface with 3D coordinate values.
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
filter=
<fes:Filter
xmlns:bldg="http://www.opengis.net/citygml/building/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Intersects>
<fes:ValueReference>
bldg:boundedBy/bldg:GroundSurface/bldg:lod2MultiSurface
</fes:ValueReference>
<gml:MultiSurface srsName="http://www.opengis.net/def/crs/EPSG/0/?????">
<gml:surfaceMember>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
21498.400088101323 17386.16611967112 31.123
<!-- ... -->
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
</gml:MultiSurface>
</fes:Intersects>
</fes:Filter>The result is shown as an image as the XML response itself is too verbose to show, and is not open data.
Query 2: Select buildings along a road
This query retrieves all buildings along a given road using the road name.
core:Address is a nested feature, and xAL requires access to an entire subtree of XML elements.
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
filter=
<fes:Filter
xmlns:bldg="http://www.opengis.net/citygml/building/2.0"
xmlns:core="http://www.opengis.net/citygml/2.0"
xmlns:xAL="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:PropertyIsLike wildCard="*" singleChar="." escapeChar="\">
<fes:ValueReference>
bldg:address/core:Address/core:xalAddress/xAL:AddressDetails/xAL:Country/xAL:Locality/xAL:Thoroughfare/xAL:ThoroughfareName
</fes:ValueReference>
<fes:Literal>Unter den Linden*</fes:Literal>
</fes:PropertyIsLike>
</fes:Filter>Query 3: Select trees within a buffer of an implicit geometry
Get all trees that are given by an LoD3 template geometry and where this
geometry is within a distance to a given geometry. core:ImplicitGeometry
is a complex data type.
|
Note
|
In CityGML 3.0 ImplicitGeometry may become a feature type, too. |
In this example, the geometry is a 3D point.
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(veg,http://www.opengis.net/citygml/vegetation/2.0)&
typenames=veg:SolitaryVegetationObject&
filter=
<fes:Filter
xmlns:veg="http://www.opengis.net/citygml/vegetation/2.0"
xmlns:core="http://www.opengis.net/citygml/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:DWithin>
<fes:ValueReference>
veg:lod3ImplicitRepresentation/core:ImplicitGeometry/core:relativeGMLGeometry
</fes:ValueReference>
<gml:Point srsName="http://www.opengis.net/def/crs/EPSG/0/?????">
<gml:pos>21498.400088101323 17386.16611967112 145.34675</gml:pos>
</gml:Point>
<fes:Distance uom="m">800</fes:Distance>
</fes:DWithin>
</fes:Filter>The result is shown as an image as the XML response itself is too verbose to show, and is not open data.
|
Caution
|
The image does not fit to the query as buildings are shown, not trees; this needs to be updated. |
Query 4: Select buildings based on ADE information
Get all buildings that have a thermal zone which contains a thermal boundary
whose u value is greater than a given value. This example uses the
CityGML EnergyADE 1.0 extension which adds energy information to the CityGML
base model.
The query involves three nested features: energy:ThermalZone,
energy:ThermalBoundary and energy:Construction.
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
filter=
<fes:Filter
xmlns:bldg="http://www.opengis.net/citygml/building/2.0"
xmlns:energy="http://www.sig3d.org/citygml/2.0/energy/1.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:PropertyIsGreaterThan>
<fes:ValueReference>
energy:thermalZone/energy:ThermalZone/energy:boundedBy/energy:ThermalBoundary/energy:construction/energy:Construction/energy:uValue
</fes:ValueReference>
<fes:Literal>2.5</fes:Literal>
</fes:PropertyIsGreaterThan>
</fes:Filter>
</wfs:Query>
</wfs:GetFeature>Query 5: Select roads with a bicycle lane
This query retrieves all roads with a traffic lane for bicycles.
This query involves the nested feature tran:TrafficArea.
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(tran,http://www.opengis.net/citygml/transportation/2.0)&
typenames=tran:Road
filter=
<fes:Filter
xmlns:tran="http://www.opengis.net/citygml/transportation/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:PropertyIsEqualTo matchCase="false">
<fes:ValueReference>
tran:trafficArea/tran:TrafficArea/tran:function
</fes:ValueReference>
<fes:Literal>cycleLane</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Filter>Query 6: Select buildings suitable for photovoltaic panels
Get all buildings having one or more roof surfaces that are suitable for
mounting photovoltaic panels (the attribute pc_class stores the suitability
class which has been precomputed.
bldg:RoofSurface is a nested feature.
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
filter=
<fes:Filter
xmlns:bldg="http://www.opengis.net/citygml/building/2.0"
xmlns:gen="http://www.opengis.net/citygml/generics/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:PropertyIsBetween>
<fes:ValueReference>
bldg:boundedBy/bldg:RoofSurface/gen:intAttribute[@gen:name='pv_class']/gen:value
</fes:ValueReference>
<fes:LowerBoundary>
<fes:Literal>2</fes:Literal>
</fes:LowerBoundary>
<fes:UpperBoundary>
<fes:Literal>3</fes:Literal>
</fes:UpperBoundary>
</fes:PropertyIsBetween>
</fes:Filter>6. Requirements analysis
|
Note
|
TODO This section will analyse the use cases and identifies the requirements that would require more complex interactions than those supported by the current draft of WFS 3.0, Part 1. |
7. Assessment of OGC and community standards
|
Note
|
TODO This section will assesses current OGC standards and community standards with respect to the use cases and the approach to a next generation of OGC services ("NextGen services") based on the approach taken by WFS 3.0. |
8. Recommendations
|
Note
|
TODO This section will provide recommendations for the most appropriate way to support the use cases within the NextGen service architecture. |
Appendix A: Revision History
| Date | Editor | Release | Primary clauses modified | Descriptions |
|---|---|---|---|---|
April 11, 2018 |
C. Portele |
0.1 |
1 |
initial version |
May 8, 2018 |
C. Portele |
0.2 |
2-8 |
add document structure, initial use case template |
May 30, 2018 |
V. Coors, C. Portele |
0.3 |
5 |
initial use cases added (work in progress) |
June 22, 2018 |
V. Coors, C. Portele |
0.4 |
5 |
additional use cases and details added (work in progress) |
June 28, 2018 |
C. Portele |
0.5 |
5 |
Update use cases, unify structure and style, add bibliography |
Appendix B: Bibliography
-
Energy Concept for an Environmentally Sound, Reliable and Affordable Energy Supply. http://www.bmwi.de/English/Redaktion/Pdf/energy-concept. Federal Ministry of Economics and Technology (2010).
-
Monien, D., Strzalka, A., Koukofikis, A., Coors, V., Eicker, U.: Comparison of building modelling assumptions and methods for urban scale heat demand forecasting. Future Cities and Environment. http://rdcu.be/oHtg. Springer Open Access (2017).
-
Nouvel, R., Mastrucci, A., Coors, V., Leopold, U., Eicker, U. and: Combining GIS-based statistical and engineering urban heat consumption modelling: Towards a new framework for multi-scale policy support. https://doi.org/10.1016/j.enbuild.2015.08.021. Energy and Buildings. 107, 204–212 (2015).
-
CitySim, http://www.kaemco.ch/.
-
Chen, Y., Hong, T., Piette, M.A.: Automatic generation and simulation of urban building energy models based on city datasets for city-scale building retrofit analysis. https://doi.org/10.1016/j.apenergy.2017.07.128. Applied Energy. 205, 323–335 (2017).
-
Coors, V. ed: OGC Testbed 13 – 3D Tiles and I3S Interoperability and Performance Engineering Report. http://docs.opengeospatial.org/per/17-046.html. Open Geospatial Consortium (2018).